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The present invention re- 
lates to the generation of an en- 
cryption key for a message to 
be transmitted over a commu- 
nications network, where there 
is no real time link between the 
encryption and decryption de- 
vices. Without limitation, one 
application of the present in- 
vention is in financial transac- 
tions between a customer, ven- 
dor and financial institution. In 
essence, the present invention 
stems from the recognition that 
if the transactions are not nec- 
essarily to occur in real time 
nor in an environment of total 
security in transmission, then 
the transaction must be con- 
sidered as unidirectional from 
the customer (or their device) 
to the issuer. Thus, from the 
customers end, a unique key is 
generated for each transaction, 
preferably without reference to 
external devices. In one form, 
the unique key protects in par- 
ticular, a PIN or the like pro- 
vided by the cardholder. However, the device issuing institution will be aware of the basic encryption key for each device, and when 
coupled with further data (in the illustrative case a random number input to a rotation or other rearrangement algorithm), the issuer can 
recover the correct key and decrypt this protected part of the transaction identification block. Also two unidirectional transactions may form 
a bidirectional transaction session. 
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TRANSACTION KEY GENERATION SYSTEM 
Technical Field 

The present invention relates to the generation of an encryption key for a 
message to be transmitted over a communications network, where there is no 
5 real time link between the encryption and decryption devices. Without limitation, 
one application of the present invention is in financial transactions between a 
customer, vendor and financial institution. 
Background Art 

Electronic messaging systems of various types have come into increasing 
10 use over the last decade. Such developments as widespread use of internal 
networks, and the increase of internet access and use, have contributed to this 
growth. 

Electronic messaging is traditionally carried out using one of several 
mechanisms. In one type of arrangement, exemplified by electronic funds 

15 transfer, all terminals are uniquely identified, the communication lines are 
considered insecure, and transaction keys are generated for each transaction 
using real time on-line links between the terminal and the host. However, such 
a system is not suitable where messages may be received out of order, as in a 
packet based system, and/or where communications real-time links may be 

20 unreliable. 

Another alternative is the use of asymmetrical key encryption, such as 
RSA, in which a public key is disseminated, with the private key held only by the 
intended receiving party. A corresponding relationship needs to be established 
to allow for two-way communications. In such systems, the same key is used for 

25 numerous transactions, which creates a security risk over time - in other words, 
the key is not unique to any given communication. 

It is an object of the present invention to provide an encryption system 
which allows for an encryption key to be generated for each message, but 
where there is no real time link required between the sender and the receiver. 

30 It is further object of the present invention to provide an encryption system 

which allows regeneration of the message encryption key by an authorised 
recipient, using data from the message. 
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Summary of the Invention 

According to a first aspect, the present invention comprises a system for 
encrypting and decrypting a message, the encrypting means comprising an 
encryption engine, and a random or pseudo-random number generator 
5 providing a numerical input to said engine, said engine in response to the 
numerical input generating a unique transaction key, said key being used to 
encrypt a message and incorporate the encrypted form in a message block, 
said message block further including said numerical input as unencrypted data, 
said decryption means being adapted to produce a corresponding decryption 

1 0 key from said random number and thereby decrypt said encrypted message. 

In essence, the present invention stems from the recognition that if the 
transactions are not necessarily to occur in real time nor in an environment of 
total security in transmission, then the transaction must be considered as 
unidirectional from the customer (or their device) to the issuer. Thus, from the 

15 customers end, a unique key is generated for each transaction, preferably 
without reference to external devices. In one form, the unique key protects in 
particular, a PIN or the like provided by the cardholder. However, the device 
issuing institution will be aware of the basic encryption key for each device, and 
when coupled with further data (in the illustrative case a random number input to 

20 a rotation or other rearrangement algoriihm), the issuer can recover the correct 
key and decrypt this protected part of the transaction identification block. 

Also two unidirectional transactions may form a bidirectional transaction 
session. 

A further aspect which is in contrast to existing electronic payment 
25 systems is that merchant data will, at least to some extent, need to be supplied 
to the cardholder for inclusion in the encrypted transaction identification block. 
Merchant data allows identification of the merchant. As the intermediary parties 
play no part in the encryption, the data will have to be provided to the cardholder 
(customer) device for encryption. Some of this data may have to be attached to 
30 the transaction identification block in a non secure environment, there may also 
be provided verification of this within the encrypted part. 
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In a still further aspect, the present invention is directed to a method of 
effecting a financial transaction as herein disclosed. 

Preferably, the encryption is performed using an encryption engine 
contained within a secure hardware element of the transmitting means. For 
5 example, the transmitting means may comprise a secure card reader in 
combination with the customer's credit or debit card, and a PC or similar device 
connected to a modem. Preferably, the message block further includes a unique 
identifier for the secure encryption means, and the decrypting device has access 
to the specific encryption engine used for that device, so that input of the 
1 0 numerical input allows the key to be re-generated separately at the decryption 
means. This provides a unique key for each message without the necessity for a 
real time link. 

Preferably, the encrypted data further includes a unique transaction 
identifier, generated from a predetermined set by the encryption means. Each 

15 encrypted message will have a unique transaction number. The decryption 
means stores a set of at least those transaction numbers which have been used. 
If a decrypted message contains an invalid or previously used transaction 
number, it can be identified as a duplication or replay of another message - 
further enhancing the system security. 

20 The present invention is particularly applicable to systems such as the 

internet, and more particularly to arrangements in which a secure transaction 
may pass through several parties before being presented to the intended 
recipient. An example of such an application-is a payment instruction from a 
party to purchase goods via the internet. The fundamental relationship to effect 

25 the payment is between the customer and the financial institution which will pay 
the vendor. Hence, the customer may send a message block to the vendor, 
including unencrypted data such as the amount, the customer's financial 
institution, and the date, together with an encrypted confirmation of these details 
and confidential details such as a credit or debit card number, a PIN ( personal 

30 identification number), the amount ( to alleviate tampering of the transaction 
value by an intermediary or the merchant ) and the customer's account details. 
The vendor may pass the message block to a bank or financial institution for 
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later submission to the customer's bank. Alternatively, if the transaction has a 
small value, the vendor may store the message blocks and submit them as a 
batch to a bank or similar financial institution, preferably in pseudo real time for 
later processing. In either case only the issuing bank and the customer have 
5 access to the relevant encryption and decryption data. Also, as the key is a 
transaction key, and indeed the underlying encryption function is preferably 
unique to a given encryption means, even if a single message is intercepted 
and decrypted by some means, the key for only that transaction will be obtained. 
Even if the encryption means is subverted, the keys used for all other encryption 
1 0 means will remain secure. 

Other applications of the inventive system will be apparent to the reader. 

Thus, the present invention provides for a transaction key to be 
generated, without a handshake between the encrypter and decrypter. 
Brief Description of the Drawings 
15 One illustrative embodiment of the present invention will now be 

described with reference to the accompanying figures, in which: 
Figure 1 is a schematic overview of a general arrangement in which the present 
invention may be used; 

Figure 2 is a block diagram illustrating one possible encryption process in the 

20 transmitting device; 

Figure 3 is an example transaction certificate format; 

Figure 4 is an example of a block message format; and 

Figure 5 illustrates an exemplary algorithm for generating a transaction key. 

Detailed Description 

25 The present invention will be described with reference to a particular 

application, that of funds transfer over a communications network such as the 
internet. However, it will be understood that with suitable modifications the 
present invention is more broadly applicable. The design and details of the 
encryption system, and receiver and transmitter elements, are not essential in 

30 detail to the present invention - it is only their functionality which defines the 
present invention. Greater or lesser levels of encryption security may be used 
depending upon the wishes of the system implemented 
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Furthermore, where # (hash) is referred to in the following text, it may 
preferably consist of, but not be confined to, any cryptographically robust One 
Way Function (OWF), such as, for exemplary purposes only AS2805 OWF, or 
Secure Hash Standard (SHS), HAVAL or MD Series. 
5 Referring to figure 1, the arrangement shown is one in which a domestic 

customer wishes to purchase goods or services from a cyber merchant - e.g. 
one accessible via the internet. The home user has a magnetic stripe or 
smartcard credit, debit or customer card, a secure device card reader, and a PC 
and modem connected conventionally for internet access. The other parties 

10 shown are the merchant, which is the vendor; the acquirer, which is the financial 
institution with whom the merchant has a relationship; the card issuer, who has 
a relationship with the customer; and the device issuer, who supplied the secure 
device card reader. It will be appreciated that less complicated arrangements 
are possible where, for example, the device issuer is the card issuer, or the 

15 merchant and customer share the same financial institution. 
A typical debit purchase transaction may operate as follows: 

1. Customer selects item(s) for home purchase from the merchant's web 
site, and initiates purchase software between the merchant's site and the home 
PC. An applicable software "shopping" application exists, with hooks to import 

20 and export data to a Secure Device attached to, for example COM2. The import 
/ export control between the application and the Secure Device will be a 
separate control protocol. 

2. Customer has a mag stripe, linked or smartcard debit card. 

3. Merchant provides purchase details - for example, merchant ID, value of 
25 transaction, and other relevant data. The merchant ID is transported securely 

(eg SSL) between the merchant's web site and the customer, for inclusion in the 
purchase certificate (TC1). 

4. Customer purchase software confirms debit and requests card reading / 
swipe. The secure device checks for correct reading of the card. 

30 5. Customer purchase software initiates "GetPIN" to secure device, which 
encrypts and stores the entered clients PIN. 
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6. Secure device concentrates encrypted PIN results with other transaction 
data. An advancing or other suitable transaction number is assigned - this may 
be simply 1, 2, etc, or selected from a more complex predefined set. 
Concatenated result is cryptographically incorporated into a transaction 

5 certificate using a second encryption process. An illustrative transaction 
certificate is shown in figure 3. This encryption may be, for example, using the 
public key of an asymmetrical key pair, issued by the device issuer. The secure 
device is capable of PIN encryption possibly with symmetric double length keys 
and is capable of encrypting multiple data blocks with a stored protected 
1 0 asymmetric YT bit modulus Secure Device Issuer public key half. The 'n' bit 
modulus may be 1024 bit, or other as considered suitable. Alternatively, the 
asymmetric encryption process 1 may be replaced with a symmetric encryption 
process using a variant key derived from a base key and the random number. 

7. Assembled purchase transaction is sent to the merchant, e.g. via email or 
1 5 Internet, see Figure 3 & 4. 

8. The transaction may be stored by the merchant for batching into a set of 
transactions for upload to the acquirer institution. A transaction transfer protocol 
is designed or exists to satisfy these requirements. 

Note: The Merchant Acquirer may or may not have issued the customer Secure 
20 Device reader and / or the customer mag stripe card. In this scenario, it is 
assumed that the Acquirer has issued neither. Thus, where the Merchant 
Acquirer has issued one or both the reader or card, simplification of these steps 
is possible. 

9. The acquirer determines, from for example unencrypted information in the 
25 message block, which institution issued the secure device sourcing the 

transaction. The transaction message provides a Secure Device identifier to be 
contained within external plain text data, as well as within the certificate. 

10. The transaction is forwarded to the secure device issuer, for certificate 
data recovery, using existing (INTERCHANGE) interbank secure communication 

30 systems. 
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11. The secure device issuer decrypts the certificate data and checks the 
transaction number against a transaction number database indicating the 

. possible transaction numbers for the device, and which of those transaction 
numbers have been used. If the transaction number has been used, the device 
5 issuer will send a message indicating an error or duplication to the acquiring 
institution. The entire recovered transaction is now sent to the acquirer, for 
normal processing and exchange with the issuing institution. The acquirer will 
then advise the merchant whether funds are cleared or not. The secure device 
issuer can verify the transaction certificate and check for device transaction 
10 duplication (replay) in the transaction number database. The checking 
application will record the current transaction in the database so it too cannot be 
duplicated and recover the transaction in an SCM (card no., $val, etc). 

12. The process proceeds as an existing interchange transaction, via the 
Acquirer. The secure device issuer can return (interchange) the reconstructed 

1 5 message data to the Acquirer for standard interchange processing. 

13. The merchant is informed if the funds are to be forwarded or not. A funds 
failure mechanism exists, to provide the merchant with payment "OK" or 
"Rejected". 

It will be appreciated that many of the elements of the system are already 
20 in use, and hence will not be explained further in detail. For example, interbank 
communications may proceed as normal - the only change is the requirement 
for involvement by the device issuer. Purchase software is already widely 
utilised for internet shopping - the only modification required is to ensure 
adequate security and controls between the software and the secure device. 
25 Similarly, the secure device may be merely a simplified version of the card 
readers currently used for POS transactions. 

A key feature of the present invention is that the secure message is 
assembled by the customer's secure device, not the merchant, with a unique 
identifier for the secure device and for the transaction, as well as the usual PIN 
30 inserted by the customer. The probity of intermediaries is not crucial to a secure 
transaction occurring. The present invention enables the device issuer to 
identify the source of the message, and verify that replay or duplication of the 
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transaction has not occurred, without any direct communication between the 
secure device and the device issuer. Moreover, no acknowledgment needs to 
be sent to the issuer's customer, other than a normal statement entry in due 
course. Moreover, the transaction certificate may also be used as a specific 
5 transaction ID, for example as an invoice number, between the customer, the 
merchant, the device issuer and the funds Issuer, for audit or reconciliation 
purposes. Even if transactions occur out of order, for example transaction 15 is 
received by the issuer after transaction 16, the transaction can still proceed and 
be confirmed as valid - this is not possible with conventional EFTPOS systems. 

1 0 The transaction described above relates to debit transactions - however, 

il could be applied to credit transactions, or to any other process where it is 
essential to confirm that the data originated from the correct source, as well as 
keep the data itself secure, but real time connection is not always possible. 
Examples include medical and insurance data, confidential reporting and 

15 negotiable security instructions. 

The present invention fully supports current standards for the interchange 
of financial institution data, and provides a complete audit trail with key 
regeneration capability. 

The merchant data is preferably sent to the customer using appropriate 

20 encryption established between the merchant and the customer. 

There are two relevant forms of encryption. They are Symmetric & 
Asymmetric respectively. 
Symmetric Keys - General 

Symmetric encryption uses a common shared key between two parties. 

25 The DES algorithm (Data Encryption Standard - DEA1), has been the 

accepted means of symmetric encryption, within the Financial Industry. 

DES has traditionally used Single Length (8 byte / 64 bit) keys, of which 
56 bits are actually used, in the encryption process. Because of increases in 
attacking computer power, single length keys must be extended to double 

30 length, using a modified encryption process. The double length key is split into 
components called Key Left and Key Right. 
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A double length key is denoted by an asterisk, e.g. *KM1. (This example 
shows Double length Masterkey number one). 
Secure Device Encryption Process 

Referring to Figure 2, the top two boxes of this diagram show the device 
5 master key. It is a ^Master Key. The key is loaded into secure device storage 
and cannot be recovered or read back outside the device. 
PIN Encryption Process for U ATE CCS 

The device *Master Key, ("KM) is loaded by the Secure Device 
ISSUER. When required to encrypt an entered PIN, the key is passed through a 
10 non linear modification algorithm, seeded by random value. (R1). 

The resultant derived Transaction Key (*S1) encrypts the PIN: 
C1 = % (PIN) = ^n(RVKM). 

The encrypted double length result, C1, together with the random seed, (R1), is 
passed to and stored by the Transaction Certificate generator. 

15 Device Transaction Tracking Process 

Each Secure Device will produce a sequentially incremented device 
transaction number (T1). Tl cannot be read in plain text prior to transaction 
certificate encryption. It can only be recovered by the Device Issuer host, during 
transaction verification. The device transaction number size will be of sufficient 

20 length to allow a reasonable time span of events to be recorded for replay 
checking and velocity checking at the host databases. The counter is never 
reset and only advances in value. At the end of its cycle life, sufficient time will 
have elapsed for the host database to recognise that roll-over to , for example, 
00000000 is a reasonable event for that particular device. 

25 Each transaction value of (T1) is placed in the Certificate generator. 

Magnetic Swipe Track 2 Data 

Any transaction will require the user to swipe a card for Track 2 or other 
relevant data to be captured. The data may also be captured from another 
source, for example a smart card data file. 

30 Track 2 contains all pertinent data to determine account details. It is 

protected by placing the entire track 2 data within the Transaction Certificate 
generator. 
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Transaction Certificate Generator 
Asymmetric Keys 

The secure Device will use an asymmetric key half, (PK1), which may be 
termed the PUBLIC key component. 
5 In reality, this key component need not be public and can be stored, in 

device secure storage, along with the device master key. 

The transaction certificate generator is an asymmetric encryption 
algorithm within the card reader device. The asymmetric key half (PK1) used to 
produce the certificate is treated, in the device, as a secure generic key, unique 
1 0 to the Secure Device Issuer. 

Note 1: Each Secure Device could have its own unique asymmetric 
key set. However, this is a waste of resources when the "Public" half of the key 
can be protected in the same way that the unique device *Master Key is stored. 
This removes the need for "PK1" certification. Device unique keys would also 
1 5 require additional Issuer host storage space. 

Note 2: Alternatively each Secure Device PK1 could be delivered, 
from the reader device, to an associated terminal PC, together with the 
assembled content of the generator ( Figure 3 illustrates an example TC1 
Format ). This might permit faster transaction certificate assembly. It would also 
20 support a case for a device unique PK1. However, this is not a preferred 
method and would greatly reduce the security of the transaction, potentially 
allowing fund values and Merchant ID etc to be altered. 

Note 3: If an asymmetric PK1 is impractical, it is possible to use a 
symmetric derivative variant of the base key, to produce a signing key in lieu of 
25 PK1. 

The transaction certificate, TC1, can only be recovered by the Secure 
Device issuer. Thus, ALL transactions must come through the device Issuer, 
before the transaction can be placed into conventional Interchange, for 
processing. 

30 This would allow selling transactions back to other card issuers, if the 

Secure Device Issuer were not the Card Issuer as well. 
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Figure 4 illustrates an example of both a symmetric and asymmetric block 
message format. 

Secure Reader device 

The reader device may be purpose built or may be existing technology. 
5 The reader can be constructed with a security processor chip capable of 
operating to industry standards. The encryption processing can be capable of 
both DES and asymmetric operation. Preferably, the asymmetric key length 
moduli is 1024 bits. A fixed timing block of output of results may be provided. 
Device power control etc may be activated by any suitable means, for example 
10 DSR or RTS type combinations or similar signals from associated equipment. 
Key Rotation Algorithm 
Referring to Figure 5, 
Base Key *KM: (Reference numeral 1) Consists of a device unique key, 128 
bits long. This key is programmed by the Issuer, into each device and also 
1 5 stored securely in the Issuer OCRF database, protected by a domain master key. 
(Conventional process). The key is recalled for each PIN decryption process, to 
derive the transaction key(s) for the current transaction. 

Random Generator (R1)L & (R2)R: (Reference numeral 2) 

The combined random components R1 and R2 are each a minimum of 64 bits 
20 long. *S1 is thus decoupled from *KM for additional protection against known 
cryptanalysis attacks, etc. The combined 16 byte resultant value is transmitted 
in the plain text message sent to the Issuer. 

Hash Function (#Fn): (Reference numeral 3) Each #Fn may be, but not 
necessarily, functionally identical. The 128 bit device key *KM is hashed to 64 
25 bits using the left and right (R1)L and (R2)R components respectively. Each 64 
bit product is denoted #1L and #2R in Figure 5 schematic. Each 64 bit hash 
product is then concatenated to produce the final 128 bit transaction key S1 
(reference numeral 4) required by the encrypt function to produce C1 (XPIN) in 
Figure 2. 
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Suitable modifications and alternatives to key lengths, algorithms and 
other terms, functions or the embodiments and examples given, as would be 
considered suitable by those skilled in the art, without departing from the 
generality of the disclosure of the present invention, are to be included within 
5 the scope of the present application. 
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THE CLAIMS DEFINING THE INVENTION ARE AS FOLl OWfr 



1. A system for encrypting and decrypting a message, the encrypting means 
comprising an encryption engine, and a random or pseudo-random number 
generator providing a numerical input to said engine, said engine in response to 
the numerical input generating a unique transaction key, said key being used to 
encrypt a message and incorporate the encrypted form in a message block, 
said message block further including said numerical input as unencrypted data, 
said decryption means being adapted to produce a corresponding decryption 
key from said random number and thereby decrypt said encrypted message. 

2. A system for effecting a financial transaction in an environment which 
lacks a relatively high level of security, including 

a key generator, issued by an acquirer or an Issuer, which generates a 
unique key for each transaction without reference to external devices, and 

a customer card which includes PIN and other relevant details which is 
encrypted by the customer device and transmitted via a transaction identification 
block, wherein 

the basic encryption key for each customer device is known by the issuer, 
and therefore the issuer can recover the correct key and decrypt the relevant 
part of the transaction identification block. 

3. A method of effecting a financial transaction in an electronic payment 
systems, comprising: 

suppling from a merchant to a customer device, merchant data for 
identifying the merchant, in consequence of trade between the merchant and a 
customer, and 

the data being included in an encrypted transaction identification block. 



4. A method of effecting a debit purchase transaction, including the steps of: 
a. Customer selects item(s) for home purchase from the merchant's 
web site, 
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b. Customer has a mag stripe, linked or smartcard debit card. 

c. Merchant provides purchase details to customer device, for 
inclusion in a purchase certificate (TC1). 

d. Customer device confirms debit and requests card reading / swipe. 

e. Customer device initiates "GetPIN" to secure device, which 
encrypts and stores the entered clients PIN. 

f. Secure device encrypts PIN and concatenates result with other 
transaction data, 

g. a transaction number is assigned 

h. assembled purchase transaction is sent to the merchant, 
L the transaction is sent to the acquirer, 

j the acquirer determines which institution issued the secure device 
sourcing the transaction from a Secure Device identifier contained within the 
data, 

k. the transaction is forwarded to the secure device issuer, for 
certificate data recovery. 

5. The method as claimed in claim 4, further including the steps of: 

I. the secure device issuer decrypts the certificate data and checks 
the transaction number against a transaction number database indicating the 
possible transaction numbers for the device, and which of those transaction 
numbers have been used to determine whether the transaction is to be valid or 
rejected, 

m. the merchant is informed if the funds are to be forwarded or not. 

■6. An encryption method and device which allows regeneration of the 
message encryption key by an authorised recipient, using data from the 
message, as herein disclose 

7. A device, system or method as herein described. 
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Fig 5. 
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